Generally, graphical analysis, simulation, and execution methods are used in modeling, design, analysis, and synthesis of engineered systems. These methods provide a visual representation of a model, such as a block diagram. The visual representation provides a convenient interpretation of model components and structure. The visual representation also provides a quick intuitive notion of system behavior. The components of a block diagram can also capture the mathematical representation of the actual system being modeled.
Historically, time-based block diagram models have been used in scientific areas, such as Feedback Control Theory and Signal Processing. Time-based block diagrams are used to study, design, debug, and refine dynamic systems representative of many real-world systems. A dynamic system (either natural or man-made) is a system whose response at any given time is a function of its input stimuli, its current state, and the current time. Such systems range from simple to highly complex systems. Physical dynamic systems include a falling body, the rotation of the earth, bio-mechanical systems (muscles, joints, etc.), bio-chemical systems (gene expression, protein pathways), weather and climate pattern systems, etc. Examples of man-made or engineered dynamic systems include: a bouncing ball, a spring with a mass tied on an end, automobiles, airplanes, control systems in major appliances, communication networks, audio signal processing, nuclear reactors, a stock market, and the like.
Professionals from diverse areas such as engineering, science, education, and economics build mathematical models of dynamic systems to better understand system behavior as it changes with the progression of time. The mathematical models aid in building better systems, which can be defined in terms of a variety of performance measures such as quality, time-to-market, cost, speed, size, power consumption, robustness, etc. The mathematical models also aid in analyzing, debugging and repairing existing systems (be it the human body or the anti-lock braking system in a car). The models may serve to educate users on the basic principles governing physical systems. The models and results are often used as a scientific communication medium between humans. The term “model-based design” refers to the use of graphical models in the analysis, development, validation, and operation of dynamic systems.
Dynamic systems are typically modeled in modeling environments as sets of differential, difference, and/or algebraic equations. At any given instant of time, these equations may be viewed as relationships between the system's output response (“outputs”), the system's input stimuli (“inputs”) at that time, the current state of the system, the system parameters, and time.
Time-based block diagram modeling has become particularly attractive over the last few years with the advent of software packages to process large amounts of data and perform a high number of computational iterations. In fact, various classes of graphical models enable a user to describe a system and related computations that can be performed on application specific computational hardware, such as a computer, microcontroller, FPGA, or custom hardware. Classes of such graphical models include time-based block diagram execution applications such as Simulink® from the MathWorks, Inc. Natick Mass., and state-based flow diagram execution applications such as Stateflow® from the MathWorks, Inc. Natick Mass., in addition to other models such as data flow diagrams, UML, VHDL, analog extension, and the like.
A common characteristic among these various forms of block diagram execution applications is that they define semantics of how to execute the diagram, and thus they specify how to model a dynamic system. Such applications provide sophisticated software platforms with a rich suite of support tools that make the analysis and design of dynamic systems efficient, methodical, and cost-effective. Furthermore, such applications can support the modeling of linear and nonlinear systems. They systems may be modeled in continuous time, sampled (or discrete) time, or a hybrid of continuous and discrete time. Systems can also be multirate, i.e., have different parts that are sampled or updated at different rates.
Time can be an inherited component of block diagram execution applications in that the results of a block diagram execution are dependent on time and as such, vary with time. In other words, a block diagram execution or model represents the instantaneous behavior of a dynamic system and models that system over time. Determining a system's behavior over time requires repeatedly executing a model of the system at intervals, called time steps, from the start of the time span to the end of the time span.
Systems may be categorized by the type of time step being used (fixed-step or variable-step). A fixed-step system is one that uses a fixed-step solver. A variable-step system is one that uses a variable-step solver. A solver is a module of the execution engine that is responsible for performing two tasks: (1) determining how far execution time should be advanced between consecutive passes through a system in order to accurately trace the system's outputs, and (2) integrating the derivative of the states of the system to obtain the actual states. Based on how solvers perform the first task, they are generally classified into two basic classes: Fixed-step solvers or Variable-step solvers. Fixed-step solvers often use explicit methods to compute the next continuous state at fixed periodic intervals of time. A variable-step solver can use either implicit or explicit methods to compute the next continuous state at non-periodic intervals of time. Generally, variable-step solvers use a form of error control to adjust the interval size such that the desired error tolerances are achieved.
Solvers can also be categorized into two classes with respect to time: continuous-time solvers and discrete-time solvers. Continuous-time solvers use numerical integration to compute a model's continuous states at the current time step from the states at previous time steps and the state derivatives. Continuous-time solvers rely on the model's blocks to compute the values of the model's discrete states at each time step. Mathematicians have developed a wide variety of numerical integration techniques for solving the ordinary differential equations (ODEs) that represent the continuous states of dynamic systems. Continuous-time solvers can further be separated into fixed-step continuous-time solvers and variable-step continuous-time solver. Discrete-time solvers exist primarily to solve purely discrete models. They compute the next execution time step for a model and nothing else. They do not compute continuous states and they rely on the model's blocks to update the model's discrete states. Similarly, discrete-time solvers can also be further separated into fixed-step discrete-time solvers and variable-step discrete-time solvers.
Simulink® is an example of an interactive graphical modeling tool that enables users to quickly create, model, simulate, and test block diagram representations of dynamic systems. Simulink® uses time-dependent models. It is suitable for simulating time-varying systems. FIG. 1 shows an example of a Simulink® model. The Simulink® model makes use of blocks and arrows to connect the blocks, when forming the model. Each arrow connecting one enabled block to another represents a signal having a value at all times. The arrow indicates the direction of the signal as the signal varies with time.
In time-based models, in order to know what happens with the system at a specific time in the future (such as at time equals 1000 seconds) the model must be initiated at a time of n seconds, where n is less than 1000 and the behavior at time n is known, and stepped through time to arrive at the 1000 second mark. For example, the model can be executed as follows in accordance with one example implementation embodiment. Input signal 100 generates an input signal and sends the signal to a Sum block 102 via link 110. Sum block 102 adds the signal from link 110 and a second link 116 and outputs the result in the form of link 112. At execution start time, link 116 has a signal of value zero. Integrator block 104 takes the signal from link 112 and performs integration on the input signal and outputs the result through link 114. Link 114 communicates the signal from the Integrator block 104 to a Scope block 108 for display, and also sends the signal to Gain block 106 through 116. Gain block 106 performs calculation on the input signal from link 114 and outputs the result through link 118 back to the Sum block 102. The Sum block 102 adds the signal from link 110 and the new updated signal from link 118 and outputs the result through link 112 to the Integrator block 104. The Integrator block 104 takes the updated signal from link 112 and performs integration on the value forwarded by the signal to produce an updated output on link 114. The model continues on until a predetermined condition is achieved, a time period is attained, or the user interrupts the execution.
Dynamic systems can also be modeled from a state-based perspective. The state of the system may be thought of as a numerical representation of the dynamically changing configuration of the system. For instance, in a model of a simple pendulum, the state may be viewed as the current position and velocity of the pendulum. Similarly, in a model of a signal-processing system that filters a signal the state would be a set of previous inputs. The system parameters are the numerical representation of the static, or unchanging, configuration of the system and may be viewed as constant coefficients in the equations modeling the system. For the pendulum example, a parameter is the length of pendulum: for the filter example, a parameter is the values of the filter taps.
Stateflow® is an example of a state-based dynamic system modeling application. Stateflow® is configured as a tool in Simulink® that can be used to design embedded systems that contain control, supervisory, or mode logic. By using Stateflow® with Simulink®, users can create models that combine state transition behavior (for example, fault detection or mode switching) with algorithmic continuous-time and discrete-time behavior (for example, feedback control or signal conditioning). Users can also create a model of the system and its environment in Simulink® and run hybrid executions to study the interactions between the two.
In Simulink®, a Stateflow® block uses a state diagram to represent an object with a discrete set of modes. These modes are known as states. A Stateflow® chart is a graphical representation of a finite state machine where states and transitions form the building blocks of the system. Stateflow® charts enable the graphical representation of hierarchical and parallel states and the event-driven transitions between them. The Stateflow® finite state machine reacts to events by changing states for the controlled object. A control object can be a motor, a pump, or any device that changes the behavior of the model to control its operation. The behavior of the object depends on what state the object is in and how the object changes from one state to another.
In the specific example application Stateflow®, the modeling process for modeling state-based executions, is embedded in Simulink®. Thus, the execution is invoked by Simulink® or some other time based dynamic modeling application, and does not run independently. In the case of Stateflow®, as execution starts, Simulink® starts its clock. When the execution engine reaches a Stateflow® block, the Simulink® clock stops ticking, and the execution engine passes information to Stateflow®, and awaits a signal back from Stateflow®. Stateflow® then performs its state-based modeling process. Once all the Stateflow® blocks finish their execution, outputs are sent to Simulink®, and the Simulink® clock starts-ticking again. Therefore, during the execution of Stateflow® blocks, the execution is instantaneous, i.e., has no time effect on the Simulink® model. All the events and state transitions that occur in Stateflow® are considered to have taken place at the specific moment in time when the clock stops.
An example of a Stateflow® form of state diagram model is shown in FIG. 2. Each arrow in the Stateflow® diagram also has values like the Simulink® arrows, but these values represent a decision value relating information that can cause one state to transition to another. The arrows in Stateflow® also indicate the direction of the signals. The exemplar Stateflow® diagram as shown in FIG. 2 is embedded in a Simulink® environment as shown in FIG. 3. The Simulink® signals are provided to Stateflow®, and Stateflow® uses this information to decide whether there are changes in states.
More specifically, in operation, a state flowchart 136 diagram is shown in FIG. 2, which corresponds to a detailed description of the flowchart 136 shown in FIG. 3. In FIG. 3, port data temp 158 receives a signal from the output of physical plant 146. Port temp_min 156 receives a value from a constant block 144 in Simulink® as the minimum set point temperature for the physical plant. Data switch 136 receives data from Simulink® constant block 140 or 142 indicating whether the switch should be on or off. Output port speed 160 on the state flowchart is then calculated based on input values 154, 156, and 158. Physical plant 146 receives data from output port speed 160 for further calculations within the physical plant 146. Within the state flowchart 136 as shown in FIG. 2, there are two states: an on state 120 and an off state 122. The default transition 126 determines the initial state is the off state 122. When an on_switch transition 130 is enabled, the enable signal passes to junction 124 and determines whether the temp 158 data is greater or equal to 30, if not, then the enable signal is passed on to signal link 132 and further finish the transition to the on state 120. Now the on state 120 is active and off state 122 inactive. The off state 122 will become active again when the off switch signal 128 is enabled, at which time the on state 120 will be inactive.
One notable difference between Simulink® (and similar dynamic modeling programs) and Stateflow® (and similar state modeling programs) is that Stateflow® models in state changes of discrete events and is implemented within the time-driven environment, whereas Simulink® is modeled in continuous time or discrete time and is the time-driven environment. Said differently, Simulink® is a time-driven engine and Stateflow® is an event-driven engine embedded and initiated in a time-driven environment.
Dynamic systems are typically modeled in execution environments as sets of equations. At any given instant of time, the equations output values that can be considered states, and can also be communicated to state flow modelers. Thus, users conventionally have the ability to model using time-driven equations, and/or event-driven models controlled by time-driven equations. For example, if a user wants to know how fast a school bus is traveling at a specific moment in time, the user can use Simulink® to model the speed of the school bus. If part of the determination of the speed is what gear the school bus transmission is in, the gear indication can be modeled in Stateflow® within the Simulink® speed model.
Stateflow®, and similar state modeling applications, are therefore utilized where the location and exact behavior of objects are not important but actions taken or completed on or by the objects are of interest. Such state flowchart models are currently invoked by the time driven dynamic modeling environments, such as that of Simulink®. Hence, if only a small number of Stateflow® calls are made by Simulink®, delays can be practically non-noticeable.
However, returning to the school bus example, if the user wants to know in the event of an emergency how fast the school children can get off the school bus, then the user must attempt a highly complex combination of time-driven equations and embedded event-driven models in time-driven environments to approximate the movement of each child off the bus. In Simulink®, such a model will also track the exact position of each child, despite the fact that whether a child has progressed one centimeter forward is not the focus of such a model. Regardless, such information must be tracked in the time dependent graphical model. Also, in such a model, the clock time that each child leaves the bus is unimportant. However, the number of children getting off the bus, the intervals between each child getting off the bus, and the position of the child as either remaining on the bus or being safely off the bus, are what is desired to be modeled. Such events are highly complex to model in time-driven model executions and state-based model executions operating in time-driven environments.
Furthermore, if a user wants to model network traffic and to determine how fast a router can relay millions of packets, it is computationally costly to use the state flowchart model within the dynamic block diagram time driven environment because such a configurations require constant calls between programs. Hence, the delay in execution output can be very noticeable, and can even approach the hardware processing limitations and bog down a execution to the point of ineffectiveness.
Accordingly, a modeling application that is event driven, and does not require a continuous time operation to execute, is desired.